Many of today's software applications which are being run on a computer system include a logging feature such as the Syslog utility provided by the GNU C library. This utility is utilized in conjunction with many operating systems, such as IBM's Z/OS, Unix, AIX and the like. Like most logging facilities, the Syslog utility is a heterogeneous network logging feature which provides one or more systems with the ability to store and process debug, trace, and error messages into a single data repository. A Syslog repository allows a system administrator or software developer to isolate problems with the system. Many applications which utilize a logging feature such as the Syslog facility simply write messages to the logging feature at the time a debug or trace point or error occurs in the system. In other words, log messages are written to a log in the order they are produced, sequentially one after another. For example, a software application may produce five log messages during its initialization and three log messages during the process of shutting itself down. If the application is started and then immediately stopped, eight log messages are written to the log in time order.
Internally, many of today's software applications are multilayered, meaning that the successful completion of a function performed at a particular layer of the application is dependent on the successful completion of a lower or higher layer. By way of example, consider an Internet Key Exchange (IKE) daemon supplying encryption keys to an internet protocol security communication (IP/SEC) stack. An IKE daemon is a software application which implements Requests for Comments (RFCs) 2407, 2408, and 2409. In particular, the IKE daemon provides two levels of keys for establishing a secure network communication path and securing the data exchange over the secure network communication path between two endpoints. The purpose of the first level or phase one is to create valid encryption keys for a limited time for the IP/SEC stack to establish the secure network communication path. Once the secure network communication path is established, the second level or phase two creates valid encryption keys to be used by the IP/SEC stack to encrypt the data between the two endpoints.
In the case of an IKE daemon, an endpoint, by way of a software application, will request a secure connection to send its data securely to another endpoint. In this example, phase two will be requested by the endpoint to secure the endpoints' data for transmission to the other endpoint. However, phase two must request a secure connection to be established from phase one. Consequently, phase one begins establishing a secure connection with the other endpoints. Once this connection is established, phase two begins generating keys to encode the endpoints data. The initial reporting of debug or trace messages and error messages or collectively referred to herein as log messages are typically from within the phase one and phase two portions of the software application. In the example above, the order of log messages to a Syslog repository could include phase two initialization messages, followed by phase one initialization, establishment, and completion messages, followed by phase two establishment and completion messages. As a result, the sequential outputting of messages in the software application makes the arrangement of messages in the Syslog facility difficult for a software developer to trouble shoot problems in phase two due to the interspersing of phase one messages. Furthermore, since the data of outputted log messages within a phase or between phases is typically not associated, each outputted log message typically becomes too large in order to provide enough useful information. Consequently, the Syslog file becomes cluttered and unorganized for the software developer to readily isolate the reported problem. Additionally, by sequentially outputting log messages when they occur, information which would be useful to be outputted with a particular log message during trouble isolation may not be available until after the particular message was logged. For example, the code section which contains a call to Syslog subsystem may not have access to the additional information or perhaps the information is not known until after the call to Syslog subsystem is invoked.
One prior approach to extracting useful information from the outputted log messages is to develop a software application to interpret the outputted log messages. However, this approach does not reduce the redundant information outputted in the log file which is typically significant. Such large outputted log files may cause network problems when being transmitting from a customer's site where a problem arises and the service engineer's site where trouble isolation is typically done.